在前兩篇，分別談了 GitFlow 及 GitHub Flow 兩種常見的 GIT 工作流程，使用上，GitFlow 常常被詬病流程太複雜，團隊成員如果對 GIT 的掌握度沒有一定的水平，很可能造成問題；而 GitHub Flow 很簡單，但如果遇到需要拆分多個區域，分作開發、驗證、測試等區域時，按照原本的 Workflow 又無法滿足，或許，就是因為都還有一些問題，因此GitLab 這家公司，提出了所謂的 GitLab Flow，可以說是 GitFlow 與 GitHub Flow 的結合。

GitLab Flow 的原則

GitLab Flow 中，只有一個主要分支 master，所有的分支都是由主要分支建立。官方給這個原則取了一個名字，稱為「upstream first」。

當有新的需求需要變更原始碼時，必須從 master 建立分支，而後開始在新建立的分支 add commits，接著透過 MR (在 GitLab Flow 中，Pull Request 在這邊稱為 Merge Request)，Code Review 等討論，合併回主要分支。到目前為止，GitLab Flow 與 GitHub Flow 都還是一樣的，一切都由主要分支開始。

不過 GitHub Flow 所有的變更都是回到主要分支，發佈的版本也是在主要分支上，而在 GitLab Flow 上，可以針對發布版本建立發佈 Production 分支，所有要發佈的需求，從主要分支上，透過 git cherry-pick 的機制，部署到 Production 分支上。(什麼是 git cherry-pick 可參見 Day 15 的介紹。)

GitLab Flow 如何解決需要有不同開發環境的問題

如果開發的工作環境除了開發環境、正式環境，在正式環境之前，還不需要經過準正式環境完整驗證後，才正式發佈正式版本，那在 GitLab Flow 怎麼解決這問題？

假設開發環境就是主要分支 master，正式分支稱為 production，而準正式分支稱為 pre-production，那麼，在 GitLab Flow 中，會定義如下圖的流程，同樣的，一切都由 master 作為起點，都有預備要發佈的需求時，則透過 git cherry-pick 的機制部署到 pre-production 上，當準正式版本上測試告一段落，則再次透過 git cherry-pick 發佈到正式分支 production 上。

GitLab Flow 發佈的風險

在 GitLab Flow 上，採用 git cherry-pick 的方式部署，如果所有新需求的分支併回主要分支採每次都 rebase 的後進行 fast-forward 的方式合併，那在 master 分支上挑選 commit 的時候，則容易造成漏挑 commit 的狀況。

因此在 GitLab Flow 中怎麼樣合併新需求的分支，就是很重要的問題，在 GitLab Flow 中，通常會採用 git merge --no-ff 或 git merge --squash 的方式；透過 --no-ff 的方式，每個需求分支在合併回去時，會把該需求對應的 commit 包覆在一個圈圈內，因此 cherry-pick 的時候，僅需要挑選圈內所有的 commit 即可完整挑選；透過 --squash 的方式，則因為每個需求的 commit 都已經被壓縮在一個 commit 裡，因此沒有漏挑的問題。

• git merge --no-ff
  
• git merge --squash
  

至於其他 GIT 合併線圖如何讓線圖更容易閱讀好整理的內容，整理在 Day 21 及 Day 22 的內容中。

GitLab Flow 的版本發佈方法

而在做 OpenSource 專案時，可能必須要面對同時維護多個穩定版本的情境，如發佈的版本同時存在 2-3-Stable 及 2-4-Stable 等多版本需要進行維護，在 GitLab Flow 中，僅需要從 master 建立新的分支，如發佈 2.3.0 版本時，則從 master 分支建立 2-3-Stable 分支；之後如有需要發佈 2.3.1 小版本 patch，則透過 master 作 git cherry-pick 挑選需要的 commit 到 2-3-Stable 分支上，同樣的 2-4-Stable 也是相同的模式。

如此的流程，即可滿足同時維護多個版本的需求，又不至於讓流程變得很複雜。

總結：

經歷連三篇，分別介紹了 GitFlow、GitHub Flow以及本篇的 GitLab Flow，介紹這些流程，主要需要了解流程想解決的事情、優缺點，真正在套用流程到開發團隊內部時，還是可以針對團隊內真正的需求做流程上的變動。

像有些公司會透過發佈流程，在做 PR/MR 前，必須確保原始碼都符合內部定義的 Coding Guideline 因此還會透過 Git Hook 機制或 CI 工具綁定格式測試，也有些公司內部定義 Code Review 必須通過至少兩個人同意。

流程沒有絕對，只有適合自己團隊的流程，才是好流程。

參考資料：

• GitLab Flow
• Introduction to GitLab Flow
• 什麼是 git cherry-pick 可參見 Day 15 的介紹
• 如何讓線圖更容易閱讀好整理的內容，整理在 Day 21 及 Day 22